home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Software Vault: The Gold Collection
/
Software Vault - The Gold Collection (American Databankers) (1993).ISO
/
cdr25
/
cw3580.zip
/
CZAR_DOC.TXT
< prev
next >
Wrap
Text File
|
1993-03-06
|
41KB
|
764 lines
Sysop Documentation for OS/2 Czarwars Game System 3.58
(C) Copyright 1987-1989 Ray Yeargin. All rights reserved.
OS/2 Adaptation, (C) Copyright 1989 Troy Carroll. All rights reserved.
A. System Requirements:
Minimum Configuration:
IBM personal computer or compatible with 2MB RAM (4MB preferable)
OS/2 1.1 SE or greater
Hard disk drive with 1 megabyte of free space
Hayes compatible modem usable through COM1 or COM2
Recommended:
Real-time, battery backed clock/calendar
Good quality surge suppressor
The following instructions in Item B are for a fast setup of the system
using default settings. Once the quick setup is completed you will be
able (at your option) to read the Configuration section of this manual
and customize your board to your individual preferences. If you are not
already familiar with Czarwars you should read the CZAR_HLP.TXT file
prior to doing the quick setup. You should also make back up copies of
the distribution disks.
B. Quick Setup for standalone mode:
NOTE: If you intend to run this software as a door under other software
using command line parameters, read section G below before
continuing here.
Hardware:
1. Ensure that your modem is set to NOT auto answer the phone.
Software:
1. Create a Czarwars directory on your hard disk and copy all the files
on the distribution disks into the directory.
All included files should be in the Czarwars directory for the
system to operate properly except for the following:
README
HISTORY.TXT
LICENSE.TXT
CZAR_DOC.TXT
2. Run CZAR_UTL.
The CZAR_UTL program will check for missing files in the Czarwars
directory and will generate new copies of the data files and
bulletins, if necessary.
You will be asked a couple of questions concerning the location and
speed of your modem. If you do not already have a map file
(CZAR_MAP.DAT) in the Czarwars directory, you will also be asked
questions about the size and type of galaxies to install in the map
file that will be generated.
You will then be asked for a name and password for the Sysop. You
should enter your name or simply 'SYSOP' at the name prompt. Both
the Sysop's name and password must be entered in UPPER CASE. This
will be the name and password you enter when you log into Czarwars.
When the automatic configuration of Czarwars is completed you will
see the Czarwars utility program main menu on your screen. You may
select option 1 (Configure the System Parameters) at this point to
further customize your installation of Czarwars.
Some items you may consider changing at this time are:
a. Select item 15 (Enable programmatic upgrades to 'A')
If you intend to ask for donations to help support your BBS then
you will probably want to leave this set to '0'. If you don't
plan to solicit donations, enter a '1' so players can upgrade
their own ships to class 'A'. (a '0' here would enable you to
give class 'A' ships to contributors only - or give them to no
one, if you prefer)
b. Select item 13 (Initialize the map). If you start with the
advanced map file you may want to 'freshen' the inventory levels
of the ports and planets. To do this enter a number from 1 to 10
to set the initial inventory levels (2 to 4 recommended).
NOTE: If you have the advanced map file and you do not run this
routine, the inventory levels will be very high when the game
first starts. As a result, the first few players to log on will
encounter planets and ports with the maximum quantitys and prices,
therefore gaining an early advantage.
3. You should now be able to run CZAR_PGM and move around on the board
as a regular player. You can buy and sell things, leave signs, and
even leave mail.
You can now bring up the BBS by entering CZAR_PGM /M. Using the /M
switch causes the program to look to the modem for incoming calls
rather than going straight to the console as before. If your modem
is on and attached to the COM: port that you selected during the
automatic installation then you should see a 'waiting for a call'
screen on your display (which can appear in any of 8 different spots
on the screen).
If the phone rings now, the system will answer it and attempt to
detect a carrier tone.
You're online! If you were actually bringing up the system you would
now turn off your monitor to save electricity and to prevent burn-in.
Of course, you also may press the escape key and bring down the
system at any time.
C. Configuring and Customizing Czarwars:
The CZAR_UTL program option <1> (Configure the System Parameters) allows
you to customize Czarwars into a unique game. When you select option
<1> you will be presented with a menu of numbered options. Lets take
them one by one in order.
1. Game Cycle in days = 8
The 'Game Cycle' controls the maximum inventories of goods at the
various ports and planets. For example, a port with a daily ore
productivity level of 20 will produce 20 cargo holds of ore per day.
If no one ports there to purchase ore for (say) several weeks then
the inventory of ore would just keep growing indefinitely - if not
for the limits imposed by the Game Cycle. If the Game Cycle is set
to 10 then the port will accumulate no more than 10 times the daily
production. 10 x 20 = 200. Therefore, if no one buys the ore to
keep the levels of inventory down, production will stop when 200
holds of ore accumulate there. When someone buys some ore thereby
causing the inventory to drop below the limit of 200 then production
of ore will resume at the 20 hold-per-day level. Commodities
produced on planets and the quantities of goods that ports attempt to
purchase are controlled in the same way.
I recommend starting with this number in the range of 6 to 12.
2. Logon Delay in 5 minute periods = 30
The Logon Delay is measured in 5 minute periods (5 minutes=1
'Starday') and controls how long a player must wait between LOGONS.
Note that the duration of the session has no bearing on when a person
is eligible to log on again.
3. Daily antimatter per player (grams) = 80000
Antimatter is fuel. The more you issue, the more a player can move
around, trade, and gamble. Class 'A' ships are given an additional
bonus above the number you enter here if the second parameter from
item #16 below is set above zero. This enables you to give (for
example) class 'A' ships a 10-100%+ antimatter bonus. The reasoning
here is that if you are soliciting donations, the extra antimatter is
an additional incentive to give. 50000-100000 grams is a good range
to stay in until you've had the board up for a while.
4. Start Holds in new ship = 25
This controls how many cargo holds are included with a new ship.
5. Start Cash issued with new ship = 5000
The number of credits ($) issued to a player getting a new ship.
6. Max Holds for A & B class ships = 125 75
The maximum number of cargo holds that class 'A' and class 'B' ships
can contain.
7. Price of a Star Base = 10000
The amount of credits a player must pay to build a type 1 Starbase.
For simplicity, this parameter is actually entered as a 'price per
fighter strength'. Since a fighter costs 100 you can easily set the
Starbase price to, say, half of the equivalent fighters price... in
this case, 50 credits per 'fighter strength'.
8. Time limit parameter in minutes = 30
This parameter is used along with antimatter quantity to determine
the time limit for a session. A session time limit is based on 2
things. First of all, each session automatically gets 5 minutes
regardless of antimatter quantities and the setting of the time limit
parameter. Second, in addition to the default 5 minutes, extra time
is issued based on the quantity of antimatter the person possesses
AND this parameter. For example, if a person has a full daily issue
of antimatter and this parameter is set to 20 they would get the 5
minute minimum and an additional 15 minutes (because of the full load
of antimatter). If the they have 10% more than the daily issue of
antimatter, then a setting of 25 would get them 27 minutes (5 + 1.1 *
20), etc. If, however, they have used half of today's issue of
antimatter in an earlier call, then a setting of 35 would yield them
only a 20 minute time limit (5 + 30/2). A setting of about 7 minutes
per 10000 grams of antimatter usually gives plenty of time. If your
system has mostly experienced players, use a smaller number.
9. Bell on time (don't ring before) = 9
This controls the bell when a person uses the <!> summon the sysop
function. Enter the hour that you want the bell enabled. For
example, if you get up at 9 am, set the parameter to 9. (use 24 hour
format). To disable the bell, set this and the 'Bell off time' to
the same number.
10.Bell off time (don't ring after) = 20
Like the 'bell on time', this controls the bell. Enter the hour in
24 hour format that you want the bell disabled. To have the bell
disabled at 8 pm, set the parameter to 20.
11.Price of player strength calculations = 1000
This is the price in credits that players will be charged to do "net
worth calculations" on other players.
12.Operating through Com: port 1 or 2 = 1
This switch tells the system which COM: port your modem is attached
to. If your modem is attached to COM2: then set this switch to 2.
13.Start Fighters with new ship = 25
This number controls the quantity of fighters issued to new players
and to players getting a new ship after losing their old one.
14.Remote Validation Password = none
This will be the secret password that you would use to validate
someone at validation level 1 (class B) remotely. It can consist of
upper case letters, numbers, and special characters. For example,
to validate JOE BLOW (a new, registered but not yet validated player)
you can call the board and enter JOE BLOW at the name prompt and then
this secret code at the password prompt. Of course, if you are at
your computer you can use CZAR_UTL to set a validation level to any
valid setting.
NOTE: Entering a password in lowercase here will disable this
feature.
15.Enable programmatic upgrades to 'A' = 0
This switch controls upgrades to class 'A' ships. If set to 1
players will be able to purchase class 'A' ships (and raise their
validation level to 2) at any class 4 port. If set to 0 they will
not be able to upgrade - you will have to do any upgrading with
CZAR_UTL. You might want to disable programmatic upgrades if you
solicit donations to your system. As an additional incentive for
your users to contribute you can then give Class 'A' ships only to
those users that do.
16.Cost of class 'A' / Antimatter bonus = 100000, 25
The first parameter (Cost of class 'A') represents the cost in
credits of an upgrade to validation level 2 (class 'A'). This is the
price a player would have to pay at a class 4 port to upgrade his
ship. Of course, this parameter is meaningless unless programmatic
upgrades (parameter #15) is enabled by setting it to 1.
The second parameter (Antimatter bonus) has an effect regardless of
the setting of parameter #15. It controls the awarding of extra
antimatter to class 'A' ships. The number represents the percentage
over the standard antimatter issue to be given to class 'A' ships.
If it is set to '50' then class 'A' ships will be given 50 percent
more antimatter than class 'B' ships. If you have programmatic
upgrades enabled, keep this one small. If, however, you set
programmatic upgrades to manual and charge your users for class 'A'
ships, you can use this to make contributions much more attractive by
setting it to give contributors an extra 10-100% (or more)
antimatter.
17.Lock out 300 baud access = 0
Setting this parameter to a '1' causes 300 baud callers to get this
message; "300 baud in not supported". Setting it to 0 enables 300
baud callers to connect. This parameter applies only in stand-alone
BBS mode [CZAR_PGM/M].
18.Modem Setup & modem options = ATS12=20S10=99S7=40E0X1V1M0
This is the setup string that is sent to initialize the modem each
time the system goes to wait for a call. It is set up for a Hayes
compatible modem but can be changed to any string up to 40 characters
long.
Other options here include :
modem reset string
modem answer string
modem hangup string
Each of these three options can be disabled by entering "NONE" (in
uppercase as shown) rather than a modem string.
In the case of the modem reset string, entering NONE will prevent
resetting the modem prior to sending the setup string each time the
program goes to wait on a caller.
Disabling the modem answer string by entering NONE will prevent a
string from being sent to the modem when the phone rings. If you do
this you will have to set your modem to autoanswer either by a
hardware switch or by putting S0=1 (or appropriate instruction) in
the setup string.
In the case of the hangup string, entering NONE will cause the system
to hangup by the 'DTR drop' method. This will be faster than using a
hangup string but may not work with all modems.
19.Modem type (1=300, 2=1200, 3=2400, 4=9600) = 2
This parameter tells the software what speed modem you have. As
indicated, enter a '1' for a 300 bps modem, '2' for 1200 bps, '3' for
2400 bps, and '4' for 9600 bps.
20.Map size (1, 2, 4, or 8) = 4
This parameter tells the program how much of the map to use. If you
set this option to 1, then players will only be able to get to the
first 500 sectors of the map. Using a 2 opens 1000 sectors and a 4
opens up the entire map of 2000 sectors. You may want to start out
with a 500 sector map and only raise it as you get additional users
(to keep it lively). I recommend setting it at 500 until you get
about 15 active players, then raising it to 1000 and raising it again
when you add 15 more players.
NOTE: Although all new maps are only 2000 sectors in size, you can
now set this option to 8. A setting of 8 will cause the CZAR_UTL
program to build a mirror image of the first 2000 sectors starting in
sector 2001. The end result will be a 4000 sector universe with all
the galaxies, planets, and ports duplicated - only reversed in
position. For example, sector 1 would be duplicated in sector 4000,
sector 2 in 3999, etc. Do not do this until your game has become
quite active. I would suggest you leave it at 2000 sectors until you
get about 40 active players.
NOTE: If you do decide to expand the map, you can use option 17
under the CZAR_UTL main menu to reorganize the galaxies in the upper
2000 sectors (using manual galaxy selection). Please note that you
can not use this option to reorganize an area in an ongoing game that
has previously been available to players - use it only on the upper
2000 BEFORE allowing players access to it.
21.Public mail fixed and char cost = 5000 10
These parameters control the cost to post public mail. The first one
(fixed cost) is a fee for posting a public message, regardless of
length. The second number (character cost) is an additional charge
for each character typed into the message. For example, a 100
character message would cost 6000 credits using the above prices
(5000 + 100 * 10).
22.Price of a sector sign = 3000
This price controls three things:
1) the price to post a sector sign
2) the refund when you remove a sign of your own
3) the fee to remove someone else's sign
If this parameter is set to 3000, then it would cost a player 3000
credits to post a sector sign. He would then be given a refund of
90% of the original price when he removed it (2700). If, however, he
attempted to remove someone else's sign, it would cost 50% above the
sign cost (4500 credits).
D. Routine system maintenance:
In addition to configuring the system and validating users CZAR_UTL has
15 other assorted maintenance functions. They are explained below:
<1> Configure the System Parameters
(explained in section C above)
<2> Validate/invalidate/change validation level
The Sysop was entered initially during the automatic installation
process with a validation level of '1'. There are other validation
levels you will need to become familiar with since you will need to
use this option to validate players.
The validation levels have the following definitions:
' ' (a space) a new player, not yet validated
'0' a player deliberately un-validated (has no access)
'1' a player validated at class 'B' ship level
'2' a player validated at class 'A' ship level.
When you need to change someone's validation level (a new, recently
verified player, for example) you can use this function. Simply
enter 2 to select this routine and then enter the name of the person
to be validated (or invalidated, as the cas may be). You will then
be asked for a new validation level for the person. Select one of
the above options and press return.
<3> List players to video or printer
This option will list all players' validation levels, names, phone
numbers, Stardate of last logon, and player number. You will be
prompted for whether you want the list to go to the video or to the
printer. This is frequently used to list new players (blank
validation level) along with their phone numbers for validation
purposes. This routine also has an option to search by validation
level. For example, if you wanted to list only those players with a
validation of 0 then you would enter a 0 at the validation level
prompt. Likewise, if you wanted only players with a space in the
validation field (new players), then you would enter an "S" for
Space. You can also use the "N" option and search through the player
file for names or name fragments. For example, if you will looking
for someone named "RAY" you would enter "RAY" as the text to search
for. You would then get a list of all players whose name contains
the fragment "RAY", regardless of where it occurs in the name.
<4> Delete players by name, date, or 0 validation
This option allows the SYSOP to purge old and inactive players from
the user file to make room for new players. It also will purge any
messages in the history file and the mail file that are addressed to
a user being purged. Any signs left by a person being deleted are
automatically removed from the map file as well. You will be
prompted for whether you want to delete users based on date (period
of inactivity), name (select a specific individual), or those with a
validation level of 0 (people un-validated by the SYSOP).
NOTE: When deleting an individual by name you MUST enter the
COMPLETE name in UPPER CASE characters.
NOTE: Deleting users by either date or validation 0 can be very
time consuming if there are a lot of players affected. Therefore, an
option has been added to terminate purging prior to completion.
Pressing the [Esc] key during these multiple user deletes will cause
the purge to terminate immediately after removing the current user.
(there may be a delay of 10 or 20 seconds before it actually quits)
<5> Edit a player record.
Be careful with this one! It allows you to change a player's name,
address, ship name, amount of fighters, amount of cash, etc.
<6> Edit map file (change ports/planets/warps)
Be very careful with this one! It lset you to change warps, add,
change, and delete planets and ports, insert and delete signs etc.
In general, it allows you to change any feature of any sector in the
universe. With it you can redesign the entire map, change
productivity of ports and planets, add and delete Pulsars and Black
Holes (and their warning signs!), create additional government
controlled sectors, and accidentally make areas with no exit!! So
again, be careful.
<7> Search map file for ships
This option will search the entire map file and report all ships
(along with the owners name) to the video. It will also report and,
at the same time, purge any 'ghost ships' (with an audible 'beep') in
the universe. A ghost ship is an image of a ship that appears in the
wrong sector. It should only happen when a player moves from one
sector to another and the power goes down between the times that the
map file and the player file are updated - causing them to get out of
sync. Though generally not serious, it does have two effects. One,
a ghost ship (invisible to other players) appears in one or more
sectors. And two, the persons ship disappears from the sector it is
really in (meaning other players cannot see any evidence of the ship
in ANY sector). The players ship will reappear as soon as the they
get back on and play out the rest of their turn.
<8> System Statistics
This item will tell you how many players there are in the player
file, how many messages in the mail file, and how many entries in the
history file. In addition to those numbers, it will also tell you
the percentage of each of the previous files that is filled - useful
when determining if you need to purge some inactive players. It will
also give you a login count. This count is the number of SUCCESSFUL
connections received by all players CURRENTLY on the user file.
Therefore, if you purge some players from the system, this number
will decrease.
<9> Scan the map for signs
This routine will search the entire map file and list all signs in
the entire universe to the screen. It also shows the user number of
the player who posted each sign (signs with a user number of 0 are
government signs). This option should be used now and then to make
sure no obscene signs are being posted in remote sectors of the
universe. If such a sign is found, you can use option <5> (Edit a
Player Record) to determine who posted it and then take appropriate
action. Also, you can easily remove any sign with option <6> (Edit
map...). Don't forget to reset 'Sign Author' back to 0 if you remove
a sign.
<10> Scan the map for fighters
This routine will search the entire map file and list all fleets of
fighters (and Starbases) guarding sectors in the universe. It will
also list the owner of each fleet of fighters.
<11> Reset a player's last logon date
This option allows you to reset a player's last 'logon time' so that
they may be able to log on and (optionally) issued the daily amount
of antimatter.
NOTE: If you reset a player's time back past midnight, they will be
issued the daily allowance of antimatter even if they have already
played today!
<12> Banish a player from the system for X days
This option allows you to reset a player's last 'logon time' so that
they will be locked out of the system for the number of days
specified.
<13> Initialize the map
(explained in section B-2 above)
<14> Initialize the game
This option is used only if you run games with time limits or
otherwise want to end a game and start a new one. The advantage that
it offers over repeating the installation process are:
1) All parameters are left as previously set.
2) All players registration information remains intact.
3) All players are notified that a new game has started.
This routine will delete everyone's ship, remove all fighters and
signs from the universe, and automatically do a map initialization
(option 13). The starting of a new game is an excellent time to
change a few parameters to better suit your boards desired
'personality'.
<15> List the map file to printer or video
This option allows you to list out sections of the map. It will
prompt you for beginning and ending sector numbers, ask whether you
want to list the map to the video or to your printer, and then
proceed to list out the section of the map you are interested in
seeing. It shows ports, warps, planets and signs.
<16> List/Purge the message file
This selection will allow you to browse through the message file,
reading and purging messages. It skips over blank messages and
prints an "*".
<17> Generate sector warps (use to reorganize galaxies in map file)
This routine is used to modify warp connections within the existing
map file. When you first bring up Czarwars this routine will be
automatically executed if needed. Therefore, it won't be necessary
to select it unless you specifically want to change around the
galaxies in the map.
NOTE: Use this only when starting a new game - it will delete
players' signs and Starbases!
===== A note to Sysops with a copy of the advanced map file =====
If you have a copy of the advanced map you may still want to re-
organize part of the map with this routine (for your first game or
two, anyway). Since this option can generate very simple maps
including easily navigated 'toroidal' galaxies, new users may find it
much simpler to move around and trade. However, it will also be less
interesting than the advanced map which has dead ends, one-way warps,
easily defended areas, and mazes. If you want a map that is half
simple and half complex you can use this routine to re-organize the
bottom 1000 sectors of the advanced map into simpler galaxies. You
may also use this routine to convert the dreaded one-way maze in
sectors 1001-1350 to simpler galaxies since it is by far the most
difficult area to navigate.
[99] Exit to OS/2
This option (the default) exits from CZAR_UTL and returns to OS/2.
E. Information on running the system:
1. Using the logfile (CZAR_LOG.TXT):
If you invoke CZAR_PGM.EXE with the /L switch, Czarwars will keep a
log of all calls. Contained in this log is information such as the
time and date that the phone was answered, the baud rate of any
successful connection, the name of the player who logged on, records
of any errors (such as i/o errors), and other information. The
logfile also can contain messages to the SYSOP by non-validated
users. Whenever a new user registers on the system for the first
time, a special entry is made in the logfile. It will include the
players phone number, name, any message that he might have left, as
well as some eye-catching characters to make it stand out from the
rest of the routine log entries. You need to look at this file often
(every day or two) so you will know when you need to validate new
users, etc. (If you run in stand-alone mode without the /L switch,
you will need to list players in the CZAR_UTL program who have a
space in their validation field). It is also useful for determining
when players are using "clone" ships - extra pseudonyms to gain an
advantage. If several players call every day, one after the other,
using the same baud rate, for example, you might look carefully to
ensure that they aren't just one player who had some friends register
and give him their passwords.
2. Terminating a user's session:
If you have need to hang up on a player, just press the [Esc] key
once. The system will then hang waiting on confirmation from you
(Really hang up on this user? [N]). If you then press "Y" and
<enter> the system will hang up and go on to wait for another call.
3. Chatting with a user:
Press the F10 function key to toggle chat mode on at any prompt.
Press F10 again to turn off chat mode.
4. Backing up the system:
Periodically (preferably every day) you need to make back up copies
of the Czarwars data files on a floppy disk. There are, of course,
many things that can happen to files on a hard disk - most of them
bad. With a day-old set of backup files you could simply reload the
game and notify your users of what had happened - not a major
inconvenience for anyone. Without backups you would be forced to
start a brand new game - which some users will no doubt find very
annoying. The only files that must be backed up are those that end
with an extension of .DAT. They are:
CZAR_PLR.DAT (the player file)
CZAR_MAP.DAT (the map of the universe)
CZAR_HST.DAT (the history file - events happening to fleets)
CZAR_MAL.DAT (the mail or message file)
CZAR_PRM.DAT (the parameter file)
CZAR_NEW.DAT (the news file)
I suggest that you compress these files with an archive program and
then freshen the archive daily. The archive file will be a small
fraction of the size of the full-blown data files and is easily
backed up. My backup archive is usually under 130K.
The logfile (CZAR_LOG.TXT) may be backed up as well, if desired. It
is possible to continue a game if you have only the player and map
files - but you will have to re-enter the configuration parameters
and players will lose their mail and history information. So, at an
absolute minimum, back up the player and map files - they are
necessary to continue the current game.
5. The Bulletin, Pre-Logon Bulletin, and Information/Rules files:
These three files are necessary for the system to run.
The bulletin file (CZAR_BUL.TXT) is an ordinary text file and can be
modified by most any word processor (in non-document mode) as well as
ASCII editors such as the OS/2 System Editor. Here is where you make
announcements and post bulletins. You should keep this one SHORT since
it lists for everyone who logs on.
The Pre-logon file (CZAR_PRE.TXT), too, is an ordinary text file. It
is displayed PRIOR to a person being prompted to log in. As a
result, it is an excellent place to identify your system, list your
hours, and possibly tell new users to use their real names. You
should also keep this one as short as possible.
The Information/Rules file (CZAR_NFO.TXT) is where you would put your
system rules and any other information about your system (such as:
Send $5 and you will be issued a class 'A' ship (more hold capacity
and 50% more antimatter)).
6. The Help file:
The help or 'instructions' file (CZAR_HLP.TXT) is required for the
system to function. It ordinarily doesn't require any modification.
7. Connection information:
Czarwars only supports 8 data bits, no parity, and 1 stop bit. 7
data bits is NOT supported. People who connect at 7 data bits will
get strange results.
8. Maps:
Paper copies of the advanced map are not available.
9. SYSOP mode:
This option is only available to the sysop (player #1). It enables
the sysop to move directly to any sector in the universe without
being attacked by fighters left on guard. It also permits the sysop
to send public mail and do player strenth calculations without
paying. In addition, it permits the sysop to list (and delete) the
log file while logged in the game. To activate it go to the
<U>tilities menu and type SYSOP. It will respond with "sysop mode
on.". To disable this mode repeat the process used to enable it. It
will respond with "sysop mode off." when disabled.
F. Performance considerations:
The following information is for OPTIONAL speed/performance improvements
to the system.
To speed disk access to the system, load all Czarwars files together
(in adjacent spots) on the disk (especially the map file and the player
file - the ones used most). Also, try to load them unfragmented. Once
loaded, they will not move around or become fragmented on their own -
they will stay in the exact spots where you put them. A program that
reorganizes disk files and unfragments them will make this task simple
(as well as improving the disk performance of other programs). Another
way to both improve disk performance while simplifying backups is to put
the entire Czarwars system in its own 2 or 3 megabyte disk partition.
Of course, optimizing the partition with a program like the one
mentioned above will further improve performance. With a very fast hard
disk drive, these changes will make only a modest improvement. However,
if you have a slow 'average access time' drive, following these
recommendations will make it seem VERY fast since the drive heads will
have only a very short distance to travel in even the worst
circumstances.
G. Doors / Running under BBSs:
There are several things to consider in addition to the advice given
above if you intend to run Czarwars as a DOOR under another BBS.
First, to run Czarwars in doors mode you must invoke it as follows:
CZAR_PGM !<port handle> <baud> <timelimit> <first name> <last name>
As you can see, a ! is used followed immediately by a decimal number
designating the handle of the communications port that Czar Wars is
to use. This is followed by a space and then a FOUR DIGIT baud
rate. Valid baud rates are 0300 1200 2400 4800 9600 1920 and
LOCA for connections at the console. If LOCA is specified, the port
handle is ignored. The baudrate is followed by a space and then the
the user's time limit in minutes. This is followed by a space and the
user's name. This name should usually consist of first and last name
separated by 1 space. It can be up to 20 characters in length. Below
is an example of what a command line might look like:
CZAR_PGM !5 9600 60 JOHN SMITH
NOTE: Any other switches that you may want to use must be placed BEFORE
the ! on the command line as follows:
CZAR_PGM /L !0 LOCA 60 SYSOP
Second, do NOT allow the parent BBS to monitor carrier.
Czarwars will terminate on its own if the user drops carrier. However,
if the BBS terminates Czarwars immediately after carrier drop (and prior to
Czarwars closing its files and terminating) some of the Czarwars files
may not be updated.
Third, since Czarwars doesn't support 7 data bits, you may want prevent
connection at 7 data bits in your BBS.
H. Common (and some uncommon) errors codes that you may see:
The most frequent error you will encounter is 'I/O error (57)'. These
will be common when there is noise on the phone line. In addition, you
will occasionally get one for no obvious reason. Another common error
is 'error code 24' (see next paragraph for more on error 24). You will
get this error whenever a user hangs up abnormally or otherwise drops
carrier. A much less likely (though still fairly common) error is
'error code 69'. This one occurs when there is a buffer overflow -
usually caused by someone uploading a message at a rate faster than the
BBS can accept it. In some circumstances, it can be caused simply by
holding the <Enter> key depressed continuously. This error will be
slightly more common with slower computers and when running the BBS in
a multi-tasked environment.
Other error codes:
64* Possibly means you have configured the BBS to use a com port that
doesn't exist. This error is sometimes followed by error 52*.
Also, error code 68* indicate possible problems with the
communications port.
53* Possibly caused by the absence of one of the required BBS files or
by too small a number of FILES declared in the config.sys file.
61* Probable cause: The disk drive containing the logfile is full.
6 Overflow/underflow. A number was used that exceeded the limits of a
variable - this usually is a response to an invalid input by a
player.
* The preceding errors flagged with an asterisk are serious and will
generally bring down the BBS. Other listed errors (57, 69, 6) should
cause no problem unless 12 or more are detected in a single session.
In that case, the system will recycle, therefore bumping off the
player who incurred the multiple errors.
Most other errors can be found in a GW-BASIC or BASICA manual.
I. Support: Registered users of OS/2 Czarwars are provided support via
"The Parkway BBS" system. The latest OS/2 version of Czarwars is
available for examination through a door there. You must be registered
on the system before you can enter the Czarwars door, however. This
system is online 24 hours a day at 9600 Hayes/2400/1200/300 BPS at 8 data
bits, no parity, and 1 stop bit.
The Parkway BBS: (904) 576-7453 or
(904) 576-4352
On your first call, leave any questions or remarks in a message to the
Sysop. Please read LICENSE.TXT for further information on registering
your copy of Czarwars.
J. Upgrades: Any registered OS/2 Czarwars Sysop can upgrade to the
latest version of OS/2 Czarwars at any time. This can be done in
one of two ways.
It is possible to remove the 'UNREGISTERED Copy!' line from new, publicly
distributed copies of Czarwars. Registered copies of Czarwars include
a file named REGISTER.COD which will include a code and instructions for
putting registration information into all future releases.
If you do not wish to download updates of Czarwars, you may also upgrade
by mail for a $10 handling fee.
Send any upgrade requests and written correspondence to:
Troy Carroll
Rt. 16 Box 9022
Tallahassee, FL. 32310-9710
K. Running Czarwars in stand-alone mode from a batch file: Czarwars will
automatically recycle when used in the /M mode. If you want to have it
exit to OS/2 after each call (and subsequently be invoked again by a
batch file) use the /1 switch:
CZAR_PGM /M /1